|
When Cognos Inc. needed to coordinate 120 developers and quality control personnel, and 100,000 source files for multiple platforms, all across a local area network, they turned to MKS Source Integrity to keep the project coordinated.
Cognos, Incorporated
Cognos Inc. is a publicly-held company with head offices in Burlington, MA and Ottawa, Ontario. Sales of its application development tools generated annual revenues of over $128 million in 1994. These tools support a wide range of open and proprietary platforms, including UNIX and the Microsoft Windows desktop (Windows 3.1, Windows 95, and, within a few months, NT). One of Cognos' products is Axiant, a visual development environment for building and deploying client/server applications. Axiant supports a three-tier client/server architecture. It features sophisticated built-in application models for generating prototype applications which users then customize to fit their environments. "We found MKS Source Integrity was easier to use." The Problem
The Axiant group involves almost 120 developers and quality control workers networked with Windows NT, Windows for Workgroups, and Windows 95 machines. They deal with over 100,000 source and construction files stored on a Windows NT server and on a UNIX machine. The problems are those of any major software project effort:
The tool the Axiant group uses to implement the solution is MKS Source Integrity.
"If I had to pick two reasons why we chose MKS Source Integrity, I'd say because it makes it easier to manage large scale projects, and because it makes it easier to port to our open systems work." The Solution
For their configuration management product, they chose MKS Source Integrity, an integrated network package which provides an excellent set of features, including network and file security, file histories and audit trails, report generation, and the sandbox TM development environment, which greatly eases both team-based development and post-release maintenance. Cognos is no stranger to configuration management or to MKS products. Hal O'Connell, the Director for Axiant Complementary Tools, says, "We were one of the very first to use CMS/MMS [ Code Management System/Module Management System] on DEC when it was introduced." That was in 1985, so Cognos now has a decade of experience in configuration management. "There is a buy-in in the company that source code management systems and object code management systems are essential. They save us a lot of grief," says O'Connell. Configuration management pays for itself in reduced quality assurance and support costs. It's less expensive to fix a bug before the product ships than after. O'Connell says, "There isn't a development manager [at Cognos] who would risk his reputation by not using [a source code management system]." Configuration management is important enough hat the Cognos Axiant group has a Build Team, who is in charge of the quality and consistency of the product's construction and file management.
Ease of Use a Key Factor
The choice of MKS Source Integrity wasn't automatic, even though various members of the team had used MKS products before. The Axiant group tested MKS Source Integrity against other products before deciding on it. "We found MKS Source Integrity was a little easier to use," says O'Connell. For example, installation and integration with our existing development environment was easier." Ease of use translates into lower internal support costs. "We have lots of developers hammering away at this [SI] and we don't want to field phone calls." Ease of use also means less frustration for users. However, the development process used at Cognos requires a certain amount of discipline from the developers. The configuration management tools must be used diligently, or the benefits are reduced. A tool that is awkward to use doesn't get used: it must be easier to use the tool than to circumvent the tool.
"Source code management systems and object code management systems are essential." There are other plusses, too. MKS Source Integrity's compatibility with UNIX RCS files meant that existing code on UNIX systems, already under RCS control, could be incorporated into the development process without loss of vital history information. O'Connell says of MKS Source Integrity, "It was a little more open." For a company that does open systems work, that's important. |
Development Model
The only way to be absolutely sure that all of the components of a piece of software work together is to build them and test the software. The more often the software is built, the sooner a problem will be caught. Many organizations build infrequently or only at significant points in the development cycle. In Cognos' Axiant group, the product is built every day. Building a version of the product every day is a matter of policy, and of pride. The development process supports it, with help from MKS Source Integrity.
For each of the hundred thousand files in the Axiant source, there is a record of every change made to that file. The entire project is checkpointed every morning. This places a marker - a "bookmark," if you will - indicating the state of the product that morning. After the day's work is finished, the product's Build Manager builds the product. The next morning, the Build Manager checks the record of the build for failures, either in the build or in the tests. "We decided to go with the daily build partially because it enforces a certain discipline on the programmers," according to Hal O'Connell. It also requires support from the corporate culture. For example, it's a matter of pride among the developers to ensure that their changes do not interfere with the construction.
Organizing the Source
The source for Axiant and the associated construction files make up about 100,00 files, stored on a Windows NT server and provided to developers and testers as needed through the LAN. MKS Source Integrity's project feature makes it possible to handle this many files. Cognos divides the files into projects of 50-100 files. Those projects are then gathered into larger projects, and those projects are gathered again into projects. Three levels of projects handle all of their files. When building the product, they don't have to build each individual project, only the top-level project. Recursion facilities in MKS Source Integrity automatically build the included projects. When they checkpoint the source (which they do daily), they only need to checkpoint the project files, rather than all 100,000 files. For each of the hundred thousand files in the Axiant source, there is a record of every change made to that file, who made it, and when the change was made, back to the beginning of file archiving. (For the files under UNIX RCS control, that predates the use of MKS Source Integrity.) At Cognos, developers use the sandbox feature of MKS Source Integrity to provide themselves with a private copy of the source as it existed at any point in its history. This copy could be of the current source or of the source that went into an ancient release. The working directory then becomes the developer's playground for testing hypotheses and trying fixes. The sandbox environment ensures that someone else's changes don't affect the stability of the developer's build. While the developer is isolated from spurious changes, the product continues to evolve. At any point, the developer in the sandbox workspace can choose to be brought up to date, to make sure that the code under development works with the current version of the product. Before introducing fixed or changed files into the source tree, a developer ensures that the code is consistent with the rest of the product. That consistency is vitally important at Cognos, and it's easy to check with MKS Source Integrity's unique sandbox feature. Only with MKS Source Integrity do developers get the benefits of stability and of up-to-the-minute file access.
Finding (and Fixing) Problems
When there is a failure, the cause is diagnosed. A problem can often be isolated to one of a set of modules just because of the nature of the problem. If the cause is not immediately obvious, the audit trail and MKS Source Integrity's report generation facility shows which files have changed in the last day. Since the problem didn't exist yesterday, the problem is somehow related to those files. The Axiant group puts the audit trail of files changed into a database. "We use the report facility to generate a database of changes to files which we report with our Impromptu product." File sets in the project currently have about 32,000 checkpoints labeled, so the product can be returned to any one of those 32,000 checkpoints.
Conclusion
Hal O'Connell says, "If I had to pick two reasons why we chose MKS Source Integrity, I'd say because it makes it easier to manage large scale projects, and because it makes it easier to port to our open systems work." He adds, "I've been using MKS products, including the Toolkit, for seven years now, and we're very happy with the set of tools MKS provides."
Contact Information
Cognos: Hal O'Connell 613-738-1338 x3348 |